Have you done any timing tests on the implementation to make sure it's correct?

Have you done any timing tests on the implementation to make sure it's correct?

I believe so, but I'll play around with the blinky example and double check that.

Have you done any timing tests on the implementation to make sure it's correct?

I ran some tests and it's a few milliseconds fast per second if I sleep repeatedly for a second. Not sure if that's worth chasing down though: it could just be core clock inaccuracy (due to internal reference).

Hmm, a delay should always delay for the minimum time specified. If it can delay less, that sounds problematic

Hmm, a delay should always delay for the minimum time specified. If it can delay less, that sounds problematic

I'll look further into it then

Hmm, a delay should always delay for the minimum time specified. If it can delay less, that sounds problematic

I'll look further into it then

@ryan-summers From what I can tell, it looks like the slight delay inaccuracy is due to inaccuracy in the HSI with which I'm running the MCUs I have. I tested other clocks and they're also running a little faster than the configured frequency (which translate to HSI deviation within datasheet limits).

I did pick up a bug in the original implementation that was making the delay actually slightly slower than it should have been and have corrected the implementation in the latest commit. I also looked at the cortex_m crate and it uses very similar logic in it's implementation. On a side note, I'm tempted just to wrap the cortex_m implementation, but it doesn't provide nanosecond resolution expected by embedded-hal-1.0.

So I think with the latest fix, this delay logic is correct. And if one wants more accurate delays, one should probably use an external oscillator, or trim the HSI differently from the factory cal somehow.